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(57) A system and method for carrying out network 
and interface selections across multiple media is dis- 
closed. The disclosed system facilitates automated net- 
work interface configuration decision-making that spans 
a set of networks supporting communications via differ- 
ing media. A set of media specific modules associated 
with differing communications media acquire network 
interface status/capabilities information. A rules engine 
thereafter applies a designated network selection rule 
(s) to the acquired network interface status/capabilities 
information, and any other appropriate parameters at- 
tributable to either an interface or network, to select one 
or more networks and interfaces with which to establish/ 
maintain a connection. 
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Description 

FIELD OF THE INVENTION 

[0001] This invention generally relates to the area of 
computer systems. More particularly, the present inven- 
tion concerns methods for selecting and determining a 
configuration for network interfaces within computing 
devices, and even more particularly in computing devic- 
es supporting multiple network interfaces associated 
with multiple differing networking media. 

BACKGROUND OF THE INVENTION 

[0002] Wireless networking has opened up a variety 
of doors to network connectivity. Today, through a com- 
bination of networking software and hardware, users are 
able to access network resources from virtually any lo- 
cation. In fact, in many instances users are able to select 
from a variety of communication media at any point in 
time. A communication medium, as used herein, refers 
to the physical as well as logical (protocol) means by 
which a user's computer communicates over a network. 
Examples of communication media include: cellular 
wireless wide area networks, personal area networks (e. 
g., Bluetooth), wireless local area networks (e.g.. 802.11 
(a/b/g)), wired local area networks, and wired wide area 
networks. Simultaneous availability of multiple commu- 
nication media arises, for example, within an office en- 
vironment that supports wireless local area network, 
wired local area network, wireless wide area network, 
and wired wide area network connectivity. 
[0003] The presence of multiple networks potentially 
reachable via a variety of technologies (e.g., wireless 
local area networks, wireless wide area networks, hard- 
wired local and wide area networks, personal computer 
area networks, etc.) introduces a need for network se- 
lection capabilities on a network-connectable comput- 
ing device. In known computing systems, in particular 
computer systems executing WINDOWS XP, automat- 
ed network selection is currently based on an order of 
identified networks in a preference list for a particular 
communications media — wireless LAN. In the prefer- 
ence list-based automated selection approach, for each 
network, the sole question when considering a current 
list entry is, "Can the computing device currently con- 
nect to the identified network?" If the answer is yes, then 
a connection is established. If the answer is no, then the 
next entry within the preference list is used (until a net- 
work connection is established). However the prefer- 
ence list approach provides a somewhat limited degree 
of flexibility in configuring a computing device to auto- 
matically connect to a network. 

SUMMARY OF THE INVENTION 

[0004] The present invention comprises a framework 
and method for selecting a network and interface based 



upon selection rules and network interface capabilities 
information spanning multiple communication media. 
The framework includes a rules data store for maintain- 
ing network selection criteria. The criteria can take on a 
5 variety forms and support selection across potentially 
multiple media. 

[0005] A media specific module interface facilitates 
acquiring network interface information associated with 
available network interfaces. The accumulated informa- 
10 tion potentially spans multiple communication media as- 
sociated with a set of networks to which the computing 
system is capable of connecting via a set of network in- 
terfaces. 

[0006] The network and interface selection frame- 
's work also includes network selection logic. The network 
selection logic is applied to the accumulated information 
to designate one of the set of networks. Thus, the frame- 
work enables network and interface selection spanning 
multiple media. 
20 [0007] The present invention is also directed to a 
method and computer-readable media for carrying out 
the functionality embodied in the above-summarized 
network and interface selection framework spanning 
multiple media types. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] While the appended claims set forth the fea- 
tures of the present invention with particularity, the in- 
30 vention, together with its objects and advantages, may 
be best understood from the following detailed descrip- 
tion taken in conjunction with the accompanying draw- 
ings of which: 

35 FIG. 1 is a simplified schematic illustrating an ex- 
emplary architecture of a computing device for in- 
corporating/carrying out an embodiment of the 
present invention; 

FIG. 2 is an exemplary multiple network communi- 
40 cation media arrangement including multiple net- 
work access points to which a mobile computing de- 
vice potentially connects; 

FIG. 3 is a schematic diagram identifying primary 
components in an automatic network selection 
45 framework within a computing device embodying 
the present invention; 

FIG. 4 summarizes an exemplary set of methods 
are identified for a public interface between a rules 
engine and a set of applications and user interfaces; 
50 FIG. 5 summarizes an exemplary set of methods 
for an interface interposed between a rules engine 
and media specific modules that interact to facilitate 
selecting and determining a configuration for net- 
work interfaces on a computing device supporting 
55 a set of network interfaces spanning multiple com- 
munication media; 

FIG. 6 summarizes a set of states of a state ma- 
chine implemented for each of a set of media spe- 
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cific modules; 

FIG. 7 summarizes a set of fields within exemplary 
network interface information passed by media spe- 
cific modules to a rules engine in response to a ca- 
pabilities query by the rules engine; 
FIG. 8 is a table summarizing automated network 
interface selection and configuration scenarios 
based upon information provided to a rules engine 
involving multiple communication media; 
FIG. 9 is a flowchart summarizing an exemplary set 
of steps for carrying out network and interface se- 
lection using the network interface selection archi- 
tecture depicted in FIG. 3; 

FIG. 10 is an exemplary scanning engine architec- 
ture for controlling scanning by network interfaces 
to facilitate reducing battery power consumption on 
a mobile computing device; and 
FIG. 11 is an exemplary set of steps of a scanning 
scheme incorporated into the scanning architecture 
identified in FIG. 10. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[0009] The illustrative network and interface selection 
architecture disclosed herein facilitates highly flexible 
automated network and interface selection decision- 
making in a multiple communication media environ- 
ment. The network and interface selection architecture 
supports decision-making by a programmable network 
and interface selection rules engine. Furthermore, the 
criteria applied by the programmable rules engine to a 
particular network interface associated with a particular 
communication media is potentially based upon capa- 
bility/policy/status/network resource information associ- 
ated with other network interfaces utilizing alternative 
communication media. 

[001 0] By way of example, the rules engine selects a 
particular network interface and network from a set of 
network interfaces and networks associated with media 
specific modules encompassing multiple communica- 
tion media, based on a set of selection rules including: 
network preference order, resources available on par- 
ticular networks, speed of the connections to the net- 
works via the particular media, etc. In an exemplary em- 
bodiment, the rules applied by the rules engine are po- 
tentially specified by a variety of sources including us- 
ers, network administrators (group policies), and net- 
work service providers. The rules are applied to network 
interface status/capabilities information provided by me- 
dia specific modules associated with a variety of com- 
munications media (e.g., wireless LAN, wireless WAN, 
wireless PAN ; wired LAN, wired WAN, etc.). 
[0011] The rules engine facilitates universal network 
selections spanning multiple media supported by a set 
of network interfaces on the computing device. In the 
exemplary embodiment, the rules engine receives sta- 
tus/capabilities information regarding each of a set of 
network interfaces associated with potentially multiple 



communication media. The rules engine executes net- 
work and interface selection decision-making according 
to the received information and network and interface 
selection rules spanning potentially multiple media. 

5 Based upon the network/interface selection results ren- 
dered during the decision-making, the rules engine ini- 
tiates configuring a selected network interface by, for ex- 
ample, issuing configuration instructions to media spe- 
cific modules associated with particular ones of the net- 

10 work interfaces affected by the network and interface 
selection results. The media specific modules in turn is- 
sue instructions to drivers associated with the affected 
network interfaces. 

[0012] FIG. 1 illustratively depicts an example of a 

15 suitable operating environment 1 00 for a computing de- 
vice (e.g. . a notebook computer) used in an environment 
including one or more networks accessed via various 
differing communication media. The operating environ- 
ment 100 is only one example of a suitable operating 

20 environment, and is not intended to suggest any limita- 
tion as to the scope of use or functionality of the inven- 
tion. Other well known computing systems, environ- 
ments, and/or configurations that may be suitable for 
use with the invention include, but are not limited to. per- 

25 sonal computers, server computers, laptop/portable 
computing devices, multiprocessor systems, microproc- 
essor-based systems, network PCs, minicomputers, 
mainframe computers, distributed computing environ- 
ments that include any of the above systems or devices, 

30 and the like. 

[001 3] The invention may be described in the general 
context of computer-executable instructions, such as 
program modules, being executed by a computer. Gen- 
erally, program modules include routines, programs, ob- 

35 jects, components, data structures, etc. that perform 
particular tasks or implement particular abstract data 
types. The invention is potentially incorporated within 
network nodes operating in distributed computing envi- 
ronments where tasks are performed by remote 

40 processing devices that are linked through a communi- 
cations network. In a distributed computing environ- 
ment, program modules are generally located in both 
local and remote computer storage media including 
memory storage devices. 

45 [0014] With continued reference to FIG. 1, an exem- 
plary system for implementing the invention includes a 
general purpose computing device in the form of a com- 
puter 110. Components of computer 110 may include, 
but are not limited to, a processing unit 120, a system 

50 memory 1 30, and a system bus 1 21 that couples various 
system components including the system memory to the 
processing unit 120. The system bus 121 may be any 
of several types of bus structures including a memory 
bus or memory controller, a peripheral bus, and a local 

55 bus using any of a variety of bus architectures. By way 
of example, and not limitation, such architectures in- 
clude Industry Standard Architecture (ISA) bus, Micro 
Channel Architecture (MCA) bus, Enhanced ISA (EISA) 
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bus ; Video Electronics Standards Association (VESA) 
local bus, and Peripheral Component Interconnect 
(PCI) bus also known as Mezzanine bus. 
[0015] Computer 110 typically includes a variety of 
computer readable media. Computer readable media 
can be any available media that can be accessed by 
computer 1 1 0 and includes both volatile and nonvolatile 
media, removable and non-removable media. By way 
of example, and not limitation, computer readable media 
may comprise computer storage media and communi- 
cation media. Computer storage media includes both 
volatile and nonvolatile, removable and non-removable 
media implemented in any method or technology for 
storage of information such as computer readable in- 
structions, data structures, program modules or other 
data. Computer storage media includes, but is not lim- 
ited to, RAM, ROM, EEPROM, flash memory or other 
memory technology, CD-ROM, digital versatile disks 
(DVD) or other optical disk storage, magnetic cassettes, 
magnetic tape, magnetic disk storage or other magnetic 
storage devices, or any other medium which can be 
used to store the desired information and which can ac- 
cessed by computer 11 0. Communication mediatypical- 
ly embodies computer readable instructions, data struc- 
tures, program modules or other data in a modulated 
data signal such as a carrier wave or other transport 
mechanism and includes any information delivery me- 
dia. The term "modulated data signal" means a signal 
that has one or more of its characteristics set or changed 
in such a manner as to encode information in the signal. 
By way of example, and not limitation, communication 
media includes wired media such as a wired network or 
direct-wired connection, and wireless media such as 
acoustic, RF, infrared and other wireless media such as 
wireless PAN, wireless LAN and wireless WAN media. 
Combinations of the any of the above should also be 
included within the scope of computer readable media. 
[0016] The system memory 130 includes computer 
storage media in the form of volatile and/or nonvolatile 
memory such as read only memory (ROM) 131 and ran- 
dom access memory (RAM) 132. A basic input/output 
system 133 (BIOS), containing the basic routines that 
help to transfer information between elements within 
computer 110, such as during start-up, is typically stored 
in ROM 131. RAM 132 typically contains data and/or 
program modules that are immediately accessible to 
and/or presently being operated on by processing unit 
1 20. By way of example, and not limitation, FIG. 1 illus- 
trates operating system 134, application programs 135, 
other program modules 136, and program data 137. 
[0017] The computer 110 may also include other re- 
movable/non-removable, volatile/nonvolatile computer 
storage media. By way of example only, FIG. 1 illus- 
trates a hard disk drive 140 that reads from or writes to 
non-removable, nonvolatile magnetic media, a magnet- 
ic disk drive 151 that reads from or writes to a remova- 
ble, nonvolatile magnetic disk 152, and an optical disk 
drive 1 55 that reads from or writes to a removable, non- 



volatile optical disk 1 56 such as a CD ROM or other op- 
tical media. Other removable/non-removable, volatile/ 
nonvolatile computer storage media that can be used in 
the exemplary operating environment include, but are 
5 not limited to, magnetic tape cassettes, flash memory 
cards, digital versatile disks, digital video tape, solid 
state RAM, solid state ROM, and the like. The hard disk 
drive 141 is typically connected to the system bus 121 
through an non-removable memory interfacesuch as in- 
terface 140, and magnetic disk drive 151 and optical 
disk drive 1 55 are typically connected to the system bus 
121 by a removable memory interface, such as interface 
150. 

[001 8] The drives and their associated computer stor- 
age media discussed above and illustrated in FIG. 1, 
provide storage of computer readable instructions, data 
structures, program modules and other data for the 
computer 110. In FIG. 1, for example, hard disk drive 
141 is illustrated as storing operating system 144, ap- 
plication programs 145, other program modules 146, 
and program data 147. Note that these components can 
either be the same as or different from operating system 
134, application programs 135, other program modules 
136, and program data 137. Operating system 144, ap- 
plication programs 145, other program modules 146, 
and program data 147 are given different numbers here 
to illustrate that, at a minimum, they are different copies. 
A user may enter commands and information into the 
computer 20 through input devices such as a keyboard 
162 and pointing device 161 , commonly referred to as 
a mouse, trackball ortouch pad. Other input devices (not 
shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 120 
through a user input interface 1 60 that is coupled to the 
system bus, but may be connected by other interface 
and bus structures, such as a parallel port, game port 
or a universal serial bus (USB). A monitor 1 91 or other 
type of display device is also connected to the system 
bus 121 via an interface, such as a video interface 1 90. 
In addition to the monitor, computers may also include 
other peripheral output devices such as speakers 197 
and printer 196, which may be connected through an 
output peripheral interface 190. 
[001 9] The computer 1 1 0 may operate in a networked 
environment using logical connections to one or more 
remote computers, such as a remote computer 1 80. The 
remote computer 180 may be a personal computer, a 
server, a router, a network PC, a peer device or other 
common network node, and typically includes many or 
all of the elements described above relative to the com- 
puter 1 1 0, although only a memory storage device 1 81 
has been illustrated in FIG. 1. The logical connections 
depicted in FIG. 1 include a local area network (LAN) 
1 71 and a wide area network (WAN) 1 73, but may also 
include other networks. Such networking environments 
are commonplace in offices, enterprise-wide computer 
networks, intranets and the Internet. 
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[0020] When used in a LAN networking environment, 
the computer 11 0 is connected to the LAN 1 71 through 
one or more wired/wireless network interfaces 170. Fur- 
thermore, the set of one or more wired/wireless network 
interfaces 170 support communications over the WAN 
173, such as the Internet. While not shown in FIG. 1 , 
computer 1 1 0 potentially includes an internal or external 
modem, connected to the system bus 121 via the user 
input interface 1 60, or other appropriate mechanism. In 
a networked environment, program modules depicted 
relative to the computer 1 1 0, or portions thereof, may be 
stored in the remote memory storage device. By way of 
example, and not limitation, FIG. 1 illustrates remote ap- 
plication programs 185 as residing on memory device 
181. It will be appreciated that the network connections 
shown are exemplary and other means of establishing 
a communications link between the computers may be 
used. 

[0021] The present invention is potentially incorporat- 
ed into mobile and non-mobile computing devices/ma- 
chines used in a variety of dynamic networking environ- 
ments. In such environments, a preferred manner in 
which to communicate potentially changes as the set of 
available media changes, the quality of service on par- 
ticular media changes, and/or the workload on various 
communication media changes. Turning to FIG. 2, a 
simple example of a wireless computing environment is 
depicted wherein the invention is potentially exploited. 
In the illustrative environment, a notebookcomputer200 
includes multiple network interface cards (not specifical- 
ly shown) facilitating communications over multiple 
communications media. In the particular example de- 
picted in FIG. 2, the notebook computer 200 communi- 
cates with a cellular transmission tower 202 (via WWAN 
media) and a wireless transceiver 204 (via WLAN me- 
dia) that is communicatively coupled to a local area net- 
work 206. 

[0022] The wireless transceiver 204 (also referred to 
as a wireless access point, or WAP), provides access 
to a variety of resources on the LAN 206. For example, 
the wireless transceiver 204 provides access by the 
notebook computer 200 to directories/files maintained 
on a file server 208. The LAN 206 also contains a gate- 
way/firewall/modem 210 providing access by users of 
the LAN 206, including the user of the notebook com- 
puter 200, to the Internet 21 2. The gateway/firewall/mo- 
dem 210 also provides access by users of the Internet 
212 to the resources on the LAN 206. 
[0023] The user of the notebook computer 200, as a 
result of the multiple supported network media, is able 
to access the Internet 212 and the file server 208 
(through the Internet 212) via multiple communication 
media. For example, utilizing a WWAN network inter- 
face, the notebook computer 200 is able to access the 
Internet 21 2 via a cellular network including the cellular 
transmission tower 202. Alternatively, the notebook 
computer 200 accesses resources on the LAN 206 via 
the wireless transceiver 204. The LAN 206 in the illus- 



trative example is assumed to include network access 
and proxy servers that enable a properly authenticated 
user of the notebook computer 200 to access resources 
of the Internet 21 2 and the LAN 206 via either of the two 

5 illustratively depicted wireless network media. The ca- 
pability of the notebook computer to access a same re- 
source via multiple media introduces the potential for se- 
lection of a particular one of the wireless network media 
based upon current conditions, needs, preferences, etc. 

10 of the user of the notebook computer 200. For example, 
other users of the network (e.g., PC 214 connected via 
wireless transceiver 204 and hardwired PCs 21 6) com- 
pete for limited network bandwidth and/or degrade qual- 
ity of communications via a particular one of multiple 

15 network media. Furthermore, the PC 21 4, due to its use 
of wireless user interface devices (a mouse and key- 
board), may create signal interference that degrades 
other wireless communications. In such instances, a rel- 
atively static preference list may not select the best con- 

20 nection available for meeting the particular needs of the 
notebook 200's current user under the current network- 
ing environment conditions. 

[0024] A rules/roaming (network and interface selec- 
tion) engine, incorporated within the notebook computer 

25 200 embodying the present invention, applies criteria to 
information pertaining to multiple supported network 
media interfaces to select one or more of the notebook 
computer 200's set of network interfaces and associated 
networks to carry out current networking needs of the 

30 notebook computer 200. The roaming engine supports 
automated network and interface selection decision- 
making for each of its multiple network interfaces based 
upon status/capabilities information supplied by multiple 
network interfaces. The roaming engine is capable of 

35 taking into account information relating to the current 
status/capabilities of other network/media combinations 
when selecting a currently preferred network and inter- 
face combination with which to establish a connection. 
In addition to a preference list, the roaming engine can 

40 base its network interface/network selection decisions 
upon: availability of particular resources, network speed 
(maximum/actual), day/time as well as any other de- 
sired factor that can be obtained by the roaming engine. 
Thus, the scope of information and breadth of factors 

45 (each encompassing potentially multiple media) that de- 
termine the notebook computer 200's multiple network 
interface configuration is significantly enhanced in com- 
parison to preference lists that merely descend a list of 
network interfaces for a single medium (e.g., WLAN), 

50 ordered by preference, until an available network inter- 
face for establishing a desired connection is identified. 
[0025] Having described an exemplary wireless net- 
working environment wherein the present invention is 
preferably incorporated, attention is directed to FIG. 3 

55 wherein an exemplary automated network and interface 
selection architecture/framework is schematically de- 
picted for incorporation into the notebook computer 200 
(or any other computing device). The network and inter- 
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face selection architecture is characterized by central- 
ized automatic network and interface selection decision- 
making/control that is incorporated into a rules engine 
300. 

[0026] Beginning at the physical network interface 
level, in the illustrative architecture, a set of N media 
specific drivers 302 of various media types (e.g., Blue- 
tooth, WWAN, WLAN — e.g., 802.11 a/b/g, etc.) are as- 
sociated with a set of N currently present network inter- 
face cards (NICs) installed on the computer 200. In the 
illustrative example, each of the media specific drivers 
302 communicates with a corresponding NIC. Such 
communications include, among otherthings, status/ca- 
pabilities information provided by the NICs. Such status/ 
capabilities information is obtained, for example, by pe- 
riodic scanning performed by the NICs upon request by 
the drivers 302. Upon request, status/capabilities infor- 
mation gathered by the N media specific drivers 302 is 
passed to the rules engine 300. The rules engine 300, 
as an aggregator/repository of all the status/capabilities 
information for all the supported NICs, stores the re- 
ceived status/capabilities information provided by the N 
media specific drivers 302 within a dynamic rules data 
store 304. In addition to scanning commands, the NICs 
also receive configuration commands from the drivers 
302. 

[0027] It is noted that, in an embodiment of the inven- 
tion, the aforementioned network interface status/capa- 
bilities information and notifications are accessible by 
applications, provisioning services 314 (e.g., a wireless 
ISP), group-policy services 312, and a user interface 
310 via a common remote procedure call API 303. By 
way of example, the common RPC API 303 includes cal- 
lable methods/operations/functions for querying and 
changing, via the user interface 310 or group policy 
services 312: preference lists, visible lists, media con- 
figurations, device states, user authentication data, and 
network configuration. In an embodiment of the inven- 
tion, the provisioning services 314 are limited to creating 
and updating network configurations that are passed 
down to the rules engine 300, and creating user authen- 
tication data through calls to the common RPC API 303. 
The above-described functions are described herein be- 
low with reference to FIG. 4. 

[0028] The rules engine 300 accesses network and 
interface selection rules, potentially spanning multiple 
communication media, from the dynamic rules data 
store 304. The network and interface selection rules 
stored within the rules data store 304 can, as shown in 
FIG. 3, come from a variety of sources including: users 
(via user interface 310) ; network administrators (via 
group policy services 312), and network access provi- 
sioning services 314 (e.g.. ISPs). In the illustrative em- 
bodiment, the Ul 310 communicates rules through the 
Common RPC API 303. However, it is contemplated that 
any source of rules potentially submits rules through a 
variety of means including directly storing the rules di- 
rectly within the rules data store as well as submitting 



the rules through a filtering entity such as the rules en- 
gine 300 or any other service supporting network device 
connections/configurations. In an embodiment of the in- 
vention, the rules engine 300 applies an order of prec- 

5 edence to sources of rules such that group policy serv- 
ices 312 rules are favored over Ul 310 supplied rules. 
The rules specified by provisioning services 31 4 are giv- 
en precedence over Ul 310 supplied rules in the event 
that a Ul 31 0 specifies such deference to the provision- 

10 ing services 314. 

[0029] The network and interface selection rules 
specify guidelines for selecting, for connection, a net- 
work and interface that utilizes a particular medium for 
data communication. Users and network administrators, 

15 for example, specify network and interface selection 
rules based upon one or more of the following factors/ 
parameters: 

1 . Resource — Internet, corporate or home. Note 
20 thatthe Internet can bespecified in finer granularity. 

Furthermore, a specific network may have multiple 
resources available. 

2. Speed — Note that a network (interface) may 
support multiple link speeds, and furthermore the 

25 specified speed is the maximum rather than the ac- 
tual connection speed (which may not be known un- 
til the connection is established). 

3. Network provider service preference order (e.g. 
MS FT, WISP1, CelM, etc.) 

30 4. Cost — the rules engine enforces a user choice 
or alternatively lets a network provider make cost 
decisions. A network which is available via multiple 
media/network interfaces has different costs asso- 
ciated with each media. Furthermore, the costs po- 
35 tentially vary dynamically based on the usage mod- 
el and are therefore periodically recalculated and 
refreshed. 

5. Power consumption — if the computing device 
is running low on power, a decision process can be 

40 invoked to switch to a medium requiring a lower 
power consumption. 

6. Location — Type of network and geographic lo- 
cation 

45 Network provisioning services are potentially available 
via a variety of media (e.g., WWAN, dial-up, DSL, etc.). 
A user, through selection rule type "3" recited above 
(network provider service preference order), potentially 
specifies a rule that defers selection of a particular me- 
50 dia to provisioning service-supplied rules. In an illustra- 
tive embodiment, the provisioning service 314 specifies 
such rules in the form of XML files. 
[0030] The rules engine 300 applies the set of selec- 
tion rules to the accumulated status/capabilities infor- 
ms mation, associated with potentially multiple media, to 
make network and interface selection decisions for the 
N network interfaces. After making a selection regarding 
a particular one of the N network interface cards and a 
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networkto which the interface should connect, the rules 
engine 300 submits configuration instructions to a par- 
ticular one of the N media specific drivers 302 that cor- 
responds to the particular network interface. The media 
specific driver thereafter passes corresponding config- 
uration instructions to the associated one of the N NICs. 
[0031] In an embodiment of the invention, a set of me- 
dia specif ic modules 320 support automatic network and 
interface selection relating to particular media types. In 
the illustrative example, the set of media specific mod- 
ules 320 include: LAN module, a WLAN module, a 
WWAN module, and a personal area network (e.g., 
Bluetooth) module. The media specific modules 320 re- 
quest capabilities/status information from the media 
specific drivers on behalf of the rules engine 300 and 
invoke scanning of network interfaces by associated 
media specific drivers of a supported media type. Upon 
request, the media specific modules pass the resulting 
acquired network information (e.g., presence, capabili- 
ties, status, etc.) to the rules engine 300. 
[0032] After making a network/interface selection 
based upon the current set of rules and information, the 
rules engine passes network interface configuration 
commands to an appropriate one (or ones) of the media 
specific modules 320 to connect to a particular network 
or networks. In responseto configuration instructions re- 
ceived from the rules engine 300, the media specific 
modules 320 initiate changes to connections associated 
with identified network interfaces via calls to associated 
media specific drivers. In the exemplary embodiment, 
each one of the media specific modules 320 incorpo- 
rates a state machine for carrying out the above-de- 
scribed functionality. An exemplary set of states for the 
state machine are described herein below with refer- 
ence to FIG. 6. 

[0033] The media specific modules 320 are associat- 
ed with two interfaces. The media specific modules 320 
communicate with the rules engine via a generalized in- 
terface incorporated into a media specific normalization 
module 322. The normalization module 322, a layerthat 
sits between the rules engine300 andthe media specific 
modules 320, facilitates standardizing communications 
between the rules engine 300 and media specific mod- 
ules 320 of many types. The normalization module 322 
facilitates: providing network driver capabilities/status 
information from the media specific modules 320 to the 
rules engine 300, and (2) specifying, by the rules engine 
300, network interface configuration commands to the 
media specific drivers 302 via the media specific mod- 
ules 320. Furthermore, the user-mode media specific 
modules 320 communicate with the media specific driv- 
ers 302, for example, according to (kernel mode) net- 
work driver interface specification (NDIS) 340. While the 
illustrative embodiment provides a media specific mod- 
ule for a particular medium type or class of media types, 
it is contemplated that alternative embodiments of the 
invention include composite media specific modules 
that support multiple, unrelated media types (e.g., a 



WWAN/WLAN media specific module). Furthermore, 
while the normalization module 322 is shown as a sep- 
arate entity from both the rules engine 300 and the me- 
dia specific modules 320, in alternative embodiments of 
5 the invention the functionality of the normalization mod- 
ule is incorporated into either the rules engine 300 or 
the media specific modules 320. 

[0034] The set of media specific modules 320 is ex- 
tensible and the individual modules are loaded and un- 

10 loaded as needed to accommodate installed network in- 
terfaces/drivers. In an embodiment of the invention, the 
ru les engine 300 registers with a notification service pro- 
vided by a data link layer (OSI layer two) module 324 
that monitors installation/removal of devices from a 

15 computing device. In a particular embodiment such no- 
tifications are carried outthrough a callback routine reg- 
istered by the rules engine 300 with the notification serv- 
ice of the data link layer module 324. Thereafter, upon 
receiving a notification from the notification service that 

20 a new network interface/device has been installed, a de- 
termination is made by the rules engine 300 whether to 
load a media specific module to handle a media type of 
the new network interface (e.g., the network interface is 
the first for the particular media type). If needed, theap- 

25 propriate media specific module is loaded by the data 
link layer module 324 upon request by the rules engine 
300, and a reference to a set of function pointers (e.g.. 
an interface table) is provided to the rules engine 300 to 
facilitate calling normalization module 322 functionality 

30 associated with the newly installed media specific mod- 
ule. Thereafter, the rules engine 300 acquires a handle 
for referencing the media specific module to initiate con- 
figuration operations (e.g., scan, connect, disconnect, 
etc.) on a media specific driver associated with the new 

35 network interface. Conversely, upon receiving notifica- 
tion that a network interface is removed, the handles 
opened on the device are disconnected/closed. If all 
sessions and handles on the media specific module, 
which can support multiple interfaces, have been 

40 closed, then the number of network interfaces is deter- 
mined. If no network interfaces remain, then an unload 
test is carried out (potentially delaying the removal for a 
period of time) prior to initiating unloading the media 
specific module. 

45 [0035] Loading/unloading media specific modules 
can be managed in a variety of ways by a variety of man- 
agement entities. In an embodiment of the invention, the 
loading and unloading of individual ones of the media 
specific modules 320 is performed by the data link layer 

50 services module 324 that is responsible for loading and 
managing the status of both the media specific modules 
320 as well as the rules engine 300. Extensibility is sup- 
ported through registration of additional media specific 
modules supporting particular identified media-types. 

55 However, such loading and unloading of program mod- 
ules can occur in any of a variety of ways, by a variety 
of entities in accordance with various embodiments of 
the invention. 
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[0036] In summary, the automatic configuration archi- 
tecture described herein above with reference to FIG. 3 
provides an extensible, highly flexible infrastructure for 
automatically selecting one or more of a set of network 
interfaces and networks based upon status/capability 
information and decision making rules that span multiple 
communication media associated with distinct net- 
works/interfaces. Thus, decision making with regard to 
configuring network connections for a set of network in- 
terfaces is not limited to network/interface information 
and rules that consider/contemplate only a single com- 
munications medium. 

[0037] Turning to FIG. 4, an exemplary set of methods 
are listed for an interface (e.g., the common RPC API 
303) between the rules engine 300 and the Ul 310, 
Group Policy Services 312 and Provisioning Services 
314. An Open method 400 creates a context handle for 
a user-mode process accessing the rules engine 300. 
A Close method 402 receives the handle previously cre- 
ated by the Open method 400 and closes the handle. A 
Close method 402 abort all pending requests and frees 
all associated resources in the rules engine 300 asso- 
ciated with the handle previously created to service re- 
quests by a caller. A Control method 404 receives as 
input a handle, GUID, Control code, Input Parameter, 
and outputs output parameters after executing non- 
standard functionality (identified by control codes) such 
as RestartAuthentication, etc. 

[0038] The set of methods exposed by the rules en- 
gine 300 to applications includes a set of methods for 
accessing/changing a list of available networks. A Que- 
ry Vis ibleList method 406 API enables the caller to re- 
quest the rules engine 300 to provide a list of available 
devices/interfaces and their associated networks. An 
optional input GUID parameter, if specified, results in 
the query being executed only for that GUID's device, 
otherwise the call will be executed across all devices 
across all loaded media specific modules. An Update- 
VisibleList method 408 causes a forced scan by the 
rules engine 300 to refresh the Visible list on either all 
devices, or if specified a particular device, and the rules 
engine 300 returns the resulting list of available net- 
works. 

[0039] The set of methods exposed by the rules en- 
gine 300 to applications includes a set of methods for 
accessing/changing a list of preferred networks. A Que- 
ryPreferredList method 410 queries the rules engine 
300 for the list of preferred networks. If a GUID or Media 
Type are specified (by flags or setting values for those 
fields), then the returned list result is filtered for that 
GUID and/or Media Type, otherwise a global list will be 
returned. An AddTo Preferred List method 412 is called 
to add an entry to the preferred list. The AddTo Pre- 
f erredList method 412 potentially fails if the preferred list 
has been modified from its last state by another caller. 
A Remove From PreferredList method 41 4 is called to re- 
move an entry from the preferred list. This potentially 
fails if the preferred list has been modified from its last 



state by another caller. 

[0040] A OneTimeConnect method 41 6 implements a 
onetime connect functionality. In other words, a tempo- 
rary state is established within the rules engine 300 for 
5 a specified entry. The connection is not persisted on any 
preferred list after the connection is completed. 
[0041] A set of methods provide access to a current 
configuration for communication media. A QueryMedi- 
aConfiguration method 418 invokes the rules engine 
10 300 to obtain and provide all parameters relating to a 
current media specific configuration. A SetMediaCon- 
figuration method 420 invokes the rules engine 300 to 
initiate setting a media specific configuration. 
[0042] A set of methods provide access to a device- 
's specific configuration. A Query DeviceState method 422 
returns a set of parameters relating to a specified de- 
vice-specific (e.g., network interface card) configura- 
tion. A SetDeviceState method 424 sets parameters as- 
sociated with a particular device-specific configuration. 
20 [0043] A set of methods provide access to authenti- 
cation data associated with a particular user. A Query- 
UserAuthData method 426 returns authentication infor- 
mation for a user identified by a specified user authen- 
tication token. A SetUserAuthData method 428 sets au- 
25 thentication data corresponding to a specified user au- 
thentication token. 

[0044] A set of methods provide access to authenti- 
cation data associated with a particular network. A Que- 
ry NetworkAuth Data method 430 returns network-spe- 
30 cific authentication information for a network identified 
by a specified network authentication token and a pro- 
vided user handle. A SetNetworkAuthData method 432 
sets authentication data corresponding to a specified 
user authentication token. 
35 [0045] The following three methods are supported by 
the common RPC API 303 of the rules engine for the 
provisioning services 214. A CreateNetworkConfigura- 
tion method 434 is similar to the above-described Set- 
NetworkAuthData method 432; however, a network con- 
40 figuration is supplied in XML format via an input param- 
eter. An UpdateNetworkConfigu ration method 436 is 
similar to the CreateNetworkConfigu ration method 434 
except that a pre-existing configuration is assumed to 
exist for the identified network. A CreateUserAuthData 
45 method 438 is similar to the SetUserAuthData method 
428 except the user data is supplied in a passed param- 
eter in XML format. 

[0046] Turning to FIG. 5, an exemplary set of methods 
are listed that are exposed by an interface provided by 
50 the normalization module 303 between the rules engine 
300 and media-specific modules 320. The set of meth- 
ods facilitates querying and configuring the devices (e. 
g., network interface cards) associated with the media- 
specific drivers viathe media specific modules 320 while 
55 avoiding the need to know any media specific imple- 
mentation requirements (handled by the normalization 
module 322). 

[0047] An Open method 500 creates a context handle 
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for the rules engine 300 for a particular identified device/ 
interface. A Close method 502 receives the handle pre- 
viously created by the Open method 500 and closes the 
handle. A Close method 502 aborts all pending requests 
and frees all associated resources in the rules engine 
300 associated with the handle previously created to 
service requests by the rules engine for the particular 
identified device. 

[0048] An Event Listener method 504 establishes a 
callback (notification) reference for the rules engine 300 
to receive identified notifications, from the normalization 
module 322. The Event Listener method 504 receives 
as input: an event notification code that identifies some 
event for which the rules engine desires notification, a 
pointer to the interface source of a notification, a pointer 
to the data of the notification, and user/context informa- 
tion. 

[0049] The set of methods exposed by the normaliza- 
tion module 320 to the rules engine300 includes a Que- 
ryVisibleList method 506 API that enables the rules en- 
gine 300 to request enumeration of a list of available 
networks for each device, media, or all devices — as 
specified by an input GUID parameter. Similarly, a Que- 
ryPreferredList method 508 facilitates querying, by the 
rules engine 300, a list of preferred networks. If a GUID 
or Media Type are specified (by flags or setting values 
for those fields), then the returned list result is filtered 
forthat GUID and/or Media Type, otherwise a global list 
will be returned. 

[0050] A set of methods provide access to the capa- 
bilities and current status of installed devices/interfaces. 
A GetDeviceCaps method 512 is called by the rules en- 
gine 300 to initiate obtaining device capabilities for an 
interface specified by the handle returned during a pre- 
vious call to the Open method 500. Examples of such 
capabilities are described herein below. In addition, the 
capabilities include device type-specific definitions for 
the interfaces. 

[0051] A set of AsyncGetxxx methods 514 and a set 
of AsynchSetxxx methods 516 facilitate obtaining and 
setting a variety of device-specific state/status parame- 
ters. The AsyncGetxxx methods 514 pass a device/in- 
terface handle that was provided for a device in re- 
sponse to the Open method 500. The AsyncGetxxx 
methods 51 4 also include an phAsync input/output pa- 
rameter whereby the rules engine 300 passes in a point- 
erto a user context value for asynchronous notifications. 
The output returned via the phAsync parameter is a 
pointer to an asynchronous notification handle. The 
handle is subsequently used to access the retrieved in- 
formation. Examples of the types of Getxxx methods 
514 include: online/offline status, signal state, visible 
providers/networks, preferred providers, ready state, 
registration state, etc. 

[0052] The AsynchSetxxx methods 516 pass a de- 
vice/interface handle, a pointer to data to be provided 
for performing the particular set functionality, and a 
pointer to a user context handle for a returned notifica- 



tion. Upon completion, the pointer references a handle 
for the request. The pointer to the user context value/ 
output handle is used as a notification mechanism to the 
rules engine 300 to signal completion or failure of the 
5 requested set function. The types of AsynchSetxxx 
methods 516 include for example instructions affecting 
the online/offline and connection status of the specified 
device/interface. 

[0053] It is further noted that in embodiments of the 
10 invention a QueryDeviceState method 518 and a Set- 
DeviceState method 520, generalized methods for de- 
termining the state of an interface and setting the state 
of an interface (corresponding to the QueryDeviceState 
method 422 and SetDeviceState method 424, respec- 
ts tively) are also supported in the normalization module 
322 or any other suitable interface interposed between 
the rules engine 300 and the media specific modules 
320. 

[0054] The interface supported by the normalization 

20 module 322 also includes a SetUserAuthData method 
522 and a SetNetworkAuthData method 524 corre- 
sponding in function to the SetUserAuthData method 
428 and the SetNetworkAuthData method 432. 
[0055] The rules engine 300, in carrying out a network 

25 interface configuration selection, submits instructions to 
establish/break connections via a connect method 526 
and a disconnect method 528. The connect method 526 
receives, by way of example, a network name (e.g. : 
SSID for WLAN or Provider and APN for WWAN), logon/ 

30 authentication information, a Pin (for WWAN), etc. 

[0056] It is noted that, having described an exemplary 
set of interfaces incorporated into an illustrative embod- 
iment of the invention, alternative embodiments of the 
invention are contemplated wherein the interfaces in- 

35 dude differing call sets for facilitating acquiring informa- 
tion about, and configuring, network interfaces in ac- 
cordance with the operation of a configuration selection 
rules engine/system as described, by way of example, 
herein. 

40 [0057] The functionality of the media specific modules 
can be carried out in a variety of ways. Turning to FIG. 
6, a set of states are identified for a state machine im- 
plemented by the rules engine 300 (or alternatively the 
normalization module 322) for each one of the set of me- 

45 dia specific modules 320 in accordance with an exem- 
plary embodiment of the modules 320. In a simplest 
form, the set of states are sequentially executed. If a 
particular state is reached within the sequence and the 
associated action is not required, then the associated 

50 action is skipped until at least a next iteration of the se- 
quence. However, in alternative embodiments, the tran- 
sitions between states are driven by state variables and 
can potentially occur in a non-sequential order, and will 
not necessarily follow the order of presentation in FIG. 

55 6. During a scan for networks state 600 a media specific 
module is called upon to query installed media specific 
drivers having a same media type for the status/capa- 
bilities information relating to each connected network. 



9 



17 



EP 1 526 682 A2 



18 



In the event that a network is associated with a provi- 
sioning service, during a look up network in provisioning 
service state 602 the media specific module issues a 
query, via the rules engine 300, to a provisioning service 
for media-specific network information. After accumu- 
lating one or more sets of network interface information, 
during a list passing state 604the mediaspecific module 
provides a list containing a set of network description 
data structures (see, FIG. 7) associated with the media 
specific module type. 

[0058] Upon receiving a call by the rules engine 300 
to configure a particular network interface, a configure 
connection state 606 of the state machine issues con- 
nection configuration instructions to a particular media 
specific driver corresponding to the network interface 
identified in the call from the rules engine 300. In the 
case where a new connection is to be established based 
upon a request from the rules engine 300, after config- 
uring a network interface at state 606, at connect to net- 
work state 608 the media specific module issues instruc- 
tions to the media specific driver associated with the se- 
lected network and interface to establish an operational 
layertwo (data-link) connection between the network in- 
terface and the identified network. During a report status 
state 61 0 the media specific state machine queries the 
driver and retrieves current connection status informa- 
tion for the specific network interface card (NIC) and 
thereafter presents the information to the rules engine 
300. 

[0059] A media specific functionality state 612 is a 
general state that is programmed according to the par- 
ticular needs of a media with which a media specific 
state machine is associated. A manage network switch- 
ing state 614 handles instances where a first network 
connection is discontinued and another one takes its 
place. The content/functionality of the manage network 
switching state 614 depends largely upon the particular 
media with which the media specific state machine is 
associated. In an embodiment of the invention, the 
switching operation is driven by the rules engine 300 
through appropriate connect/disconnect instructions. 
However, in alternative embodiments the switching op- 
eration is driven at lower levels by, for example, the nor- 
malization module 322. 

[0060] Turning briefly to FIG. 7 a set of fields associ- 
ated with an exemplary network interface descriptor da- 
ta structure is provided. The network interface descrip- 
tor is provided by media specific modules 320 to the 
rules engine 300 to facilitate network and interface se- 
lection across potentially multiple communication me- 
dia. A single media specific module, responsible for 
scanning multiple network interfaces for a particular me- 
dium, supplies a list of such descriptors corresponding 
to each of the scanned network interfaces. The rules en- 
gine 300 accumulates the network interface descriptors 
provided by the set of media specific modules and ap- 
plies a network and interface selection criteria to the ac- 
cumulated descriptors. Thereafter, the rules engine 300, 



upon selecting a network/interface combination, speci- 
fies configuration instructions to the media specific mod- 
ules 320 to implement the network/interface selection. 
The media specific modules 320 thereafter carry out the 
5 configuration instructions to connect to (or disconnect 
from) a specified network associated with a particular 
network interface. 

[0061] In an exemplary network interface descriptor, 
a descriptor handle field 700 stores a unique identifica- 
tion assigned to a particular instance of a descriptor for 
a network interface. The handle value provides a refer- 
ence for a particular instance of the combination of sta- 
tus/capability information described herein below for a 
particular network interface. A network name field 702 
stores a value uniquely identifying a network with which 
the network interface is associated. A resources field 
704 generally identifies a network resource accessed 
via the network interface. The resource field 704 sup- 
ports rules-based network and interface selection that 
is based upon a need to access a particular resource 
such as a corporate LAN, the Internet, etc. A speed field 
706 stores a value indicating the maximum data rate 
currently supported by the particular network interface. 
A cost field 708 is used to specify a cost associated with 
using the particular network. The costfield 708, in a sim- 
plest case, merely states whether or not the network 
connection does not incur a cost on a per use basis. 
Alternatively, cost can be a weighted number used to 
compare the relative cost associated with particular 
ones of multiple networks. The cost field 708 supports 
rules-based decision making where cost is a factor 
when deciding whether or not to select a particular net- 
work interface (over other available network interfaces) 
for establishing a connection. A domain name field 710 
specifies an optional domain name (e.g., Microsoft.com) 
It is noted that the present invention contemplates a 
broad spectrum of network interface description formats 
and thus the above-described example should not be 
construed as limiting the invention. The above set of de- 
scriptor fields is intended to be exemplary. Other poten- 
tially used fields include: wireless/wired media type, 
sub-types of a particular wireless media type (e.g. 
802. 1 1 a/b/g subtypes for WLAN media), authentication 
mode, encryption mode, etc. 

[0062] The following is an example of an accumulated 
set of network interface descriptors provided to the rules 
engine 300 by the 802.11 media specific module and 
the WWAN module. The first three descriptors were pro- 
vided by the 802.11 module, the last descriptor was pro- 
vided by the WWAN module. It is noted that a descriptor 
can specify a set of resources — as shown, by way of 
example, in the third descriptor identified by the handle 
"GUID3." 

{GUID1}; SSID1; Internet; 11 Mbps; free; 
wisp2.com 

{GUID2}; SSID1; Internet; 11 Mbps; free; 
wispl .com 
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{GUID3}; SSID2; Internet, corporate; 11 Mbps; free; 
microsoft.com 

{GUID4}; APN1; Internet; 384 kbps; free; 
wispl .com 

5 

[0063] Having described a general framework for a 
rules engine based automatic network connection con- 
figuration facility embodying the present invention, at- 
tention is directed to a table set forth in FIG. 8 that con- 
tains a set of exemplary network and interface selection 10 
scenarios that span multiple communication media. 
Such criteria are implemented by the rules engine 300 
based upon network interface descriptors of the type de- 
scribed, by way of example, above. 

[0064] In a first scenario set forth in the first row of the is 
table, a rule applied by the rules engine 300 specifies 
one media over one or more others. Specific scenario 
examples include specifying: a media type (e.g. , WLAN 
overWWAN), highest data transmission rate, a sub-type 
of media (e.g., 802.11aover802.11b). Parameters used 20 
in such a rule scenario include: link speed, physical me- 
dia (wire/wireless), 802.11 type (a/b/g), and cost. 
[0065] In a second scenario set forth in the second 
row of the table, a rule applied by the rules engine 300 
specifies one network over one or more others. A spe- 25 
cific scenario example is specifying a corporate LAN 
over a public wireless LAN network provided by a wire- 
less internet service provider (WISP). Parameters used 
in such a rule scenario include network identifier types 
(e.g., SSID for WLAN and APN for WISP). 30 
[0066] In a third scenario set forth in the third row of 
thetable, a rule applied by the rules engine 300 specifies 
a network preference order based upon current location . 
Specific scenario examples include specifying: WISP A 
over WISP B in the United States and WISP B over 35 
WISP A when located in Europe. A parameter used in 
such a rule scenario is location (e.g., home, work, phys- 
ical location, etc.). 

[0067] In yet another scenario, provided in the fourth 
row of the table, a rule applied by the rules engine 300 40 
specifies a preference order comprising logical net- 
works. A specific scenario example includes specifying: 
a corporate network over WISP A over WISP B. A net- 
work provider decides which physical network (WLAN 
over WWAN) to use based upon XML provisioning. Pa- 45 
rameters used in such a rule scenario include: XML pro- 
visioning files from a wireless provider, business logic 
to facilitate dynamic network and interface selection. 
[0068] In still yet another scenario, preferences are 
designated based upon a time of day. In instances 50 
where certain networks/interfaces are preferred based 
upon the time of day, a preference can be implemented 
based upon the currently detected time. For example, if 
a particular WWAN network provider is preferred on 
nights and weekends while another provider is preferred 55 
during weekdays, then a rule is submitted to, and ap- 
plied by, the rules engine 300 to render a configuration 
selection (comprising a combination of a designated 



network and interface for establishing a connection to 
the network). 

[0069] In general, the rules engine accesses rules to 
decide networks to select associated with potentially 
multiple media types. The rules are specified through a 
user interface (e.g., a dialog that accompanies the 
launch of a particular application or service), a group 
policy specified by an administrator, or a network provi- 
sioning service. These rules can be either one, or a com- 
bination, of: 

rules a user specified for establishing a network 
connection (e.g., user specifies WLAN media over 
WWAN media). 

a preference order specified by a network service 
provider. Depending on the rules in operation, the 
rules engine can specify network connections on 
each available media, or can specify network con- 
nections on one media type only and block connec- 
tions on others. 

the rules a network provider provisioned, if the user 
elects to defer to the network provider (example: 
WISP1 is the most-preferred network provider but 
is available via multiple media. WISP1 decides 
which physical network to use to connect). 

[0070] Turning to FIG. 9, a flowchart summarizes an 
exemplary set of steps for carrying out wireless media 
configuration using the configuration architecture de- 
picted in FIG. 3. The operation of the rules engine ap- 
plying a current set of network and interface selection 
ru les to a current set of available devices and associated 
networks can be initiated under a variety of conditions. 
For example, if a scan of all devices is performed that 
returns a new device state (e.g. , a new network is avail- 
able), upon receiving a notification from the data link lay- 
er services module 324 that an interface has been add- 
ed/removed, a new rule or set of rules is specified, a 
connection was broken, a network/logical location 
changed, policy or provisioning changes have occurred, 
etc. 

[0071] As a preliminary step to performing network 
and interface selection, during step 900 the rules engine 
300 receives status/capability information arising from 
the set of network interfaces across multiple communi- 
cation media (e.g., a WWAN interface and a WLAN in- 
terface). Such information is provided to the rules en- 
gine 300, by way of example, in a standardized format 
by one or more of the media specific modules 320 via 
the normalization module 322. In the case of a new de- 
vice arrival, as an initial preliminary step, the rules en- 
gine 300 requests the data link layer services module 
324 to load an associated media specific module (if not 
already loaded) and passes back appropriate referenc- 
es to the media specific module. 
[0072] The status/capability information is accumulat- 
ed/updated by the rules engine 300 in a variety of ways. 
In the illustrative embodiment of the invention, the infor- 
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mation is acquired by the rules engine 300 by actively 
querying (polling) the media specific modules 320 in ac- 
cordance with a scanning algorithm described, by way 
of example, herein below, as well as receiving unsolic- 
ited updates of the status/capabilities of network inter- 
faces from the modules 320 that receive data from me- 
dia drivers that potentially execute there own versions 
of a scanning algorithm. 

[0073] The media specific modules 320, in turn, ob- 
tain the network interface status/capability information 
from the media specific drivers 302 in any suitable man- 
ner including either or both push and pull data acquisi- 
tion procedures. In an embodiment of the invention, 
wireless media specific modules (either on their own in- 
itiative or in response to an asynchronous request from 
another entity associated with network interface config- 
uration) pull the information from the drivers 302 based 
upon scanning algorithms that are formulated to take in- 
to account a variety of factors including: current power 
source (e.g., battery), current connection state (wired/ 
wireless), duration of current connection, whether the 
computing device is presently moving, etc. In a particu- 
lar wireless scanning arrangement, a scanning engine 
associated with a wireless media specific module ap- 
plies a scanning algorithm based upon a set of scanning 
parameters including historical information maintained 
within a scanning history table to determine when to 
commence a next scan cycle for a network interface (or 
set of network interfaces). When the time for a next 
scanning period arrives, the media specific module 
commences scanning the affected network interfaces 
and stores the scan results. 

[0074] During step 910 the rules engine 300 accesses 
a set of rules specified by either one or a combination 
of rules sources including: the user interface 310, group 
policy services 312 and the provisioning services 314. 
In the exemplary embodiment of the invention, the rules 
engine 300 retrieves the network interface configuration 
rules from the dynamic rules data store 304. As men- 
tioned previously above, the rules potentially encom- 
pass multiple media. 

[0075] Periodically or upon asynchronous request, at 
step 920 the rules engine 300 applies the network and 
interface selection rules, accessed during step 910 and 
spanning potentially multiple communications media, to 
the received information to select one or more network 
interfaces for connecting to one or more particular net- 
works and render configuration instructions for each of 
the set of network interfaces corresponding to the set of 
media specific drivers 302 forthe selected interface/net- 
work combinations. Selecting a particular network for a 
network interface is needed in situations where a single 
network interface, such as a wireless LAN transceiver, 
is capable of accessing multiple networks. 
[0076] Thereafter at step 930, the rules engine 300 
issues configuration commands to the media specific 
drivers 302 via the media specific modules 320. In the 
case where a network interface status is unchanged by 



the results of step 920, there is no need to issue a con- 
figuration command. However, in cases where status 
does change for a particular network interface, the rules 
engine 300 issues an appropriate configuration instruc- 
5 tion to a corresponding media specific module to carry 
out the change and waits for confirmation by the media 
specific modulethat the instruction has been carried out. 
[0077] Having described an exemplary set of steps for 
carrying out network interface configuration decision- 
10 making across multiple media, it is noted that the above 
steps are merely exemplary. As those skilled in the art 
will appreciate in view of the disclosure contained here- 
in, the individual steps are intended to show a progres- 
sion of data/processing flow that results in set of conf ig- 
15 uration instructions issued by the rules engine to appro- 
priate ones of the media specific modules 320. Thus, by 
way of example, the acquisition of network interface in- 
formation can occur while the rules engine is obtaining 
the configuration rules that are to be applied to the net- 
20 work interface information. 

[0078] Turning now to FIGs. 1 0 and 1 1 , scanning for 
wireless networks is performed periodically by wireless 
network interface cards in support of the above-de- 
scribed network and interface selection architecture/ 
25 method described herein above — even when a user 
has no intention/need to connect to any networks 
sensed by the wireless NICs. A wireless network scan- 
ning engine 1 000 operating under the control of a scan 
algorithm 1010 described herein below varies scanning 
30 frequency of a wireless NIC 1020 based on a current 
state of a wireless NIC as evidenced by information 
stored in a scan history 1030. 

[0079] In summary of a general scanning algorithm 
implemented by the scanning engine 1000, when the 
35 wireless NIC 1 020 is not associated with a wireless net- 
work, and has not been associated for a significant pe- 
riod, scanning frequency is reduced. Additionally, when 
the NIC 1020 has been associated with the same ac- 
cess point for a significant period of time with good sig- 
40 nal strength, scanning frequency is again reduced be- 
cause the client application relying upon the wireless 
connection associated with the NIC is less likely to need 
to roam/switch to another access point or network. This 
is especially true if a laptop or other battery powered 
45 computing device containing the NIC 1 020 is not active- 
ly transmitting data packets. Reducing the scanning fre- 
quency, in accordance with the above scanning algo- 
rithm, conserves laptop battery power as the card can 
be powered down for longer periods of time between 
50 scans. 

[0080] Referring now to FIG. 1 1 , a set of steps are de- 
picted for a repeating sequence of steps governing the 
operation of the scanning engine. Initially, during step 
1100, the scanning engine invokes the NIC 1020 (e.g.. 
55 a WLAN NIC) to scan for available networks in a known 
manner and the resulting information is stored in the 
scan history 1 030. During step 1 1 1 0 the results are also 
stored in a network interface driver associated with the 
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N IC 1 020 (and later passed up to a corresponding me- 
dia specific module). Thereafter, during step 1120 the 
scanning engine 1000 determines a scanning delay pe- 
riod based ; at least in part, upon a scanning algorithm 
1010 (described further below) and previously stored 5 
scanning results in the scan history 1 030. Thereafter, at 
step 1130 a scan delay period is set for performing a 
next scan of the NIC 1020. Thereafter, control passes 
to a wait stage 1140 until the delay time period expires 
and control returns to step 1 1 00 and a next scan is per- 10 
formed. 

[0081] Having described an exemplary scan proce- 
dure, a general scan control scheme is described herein 
below. Initially, the power mode of the computing device 
will govern whetherto enable the scan timing algorithm, is 
By way of example, the scan timing algorithm is imple- 
mented when the computer is on battery power and the 
NIC is not in continuous access mode. 
[0082] Scanning is intended to ensure that a comput- 
ing device can roam successfully. By scanning regularly, 20 
the computing device should not be able to move too far 
from the currently associated access point without as- 
sociating with another access point (roaming). In ac- 
cordance with embodiments of the invention store re- 
sponses to previous scans so that it can adaptively tune 25 
the scanning period. The scanning scheme addresses 
the following cases: 

1 . When there is no network visible or the user fails 

to associate to a particular network. 30 

2. When the laptop has been associated to the 
same access point for a significant length of time 
and the signal strength is still sufficient. This indi- 
cates that the user is not moving and it is not nec- 
essary to scan for other networks or access points. 35 

3. When the user laptop is physically moving so that 
it can perform a scan for available networks before 
the user moves out of range of an access point 

[0083] In cases 1 and 2, the interval between scans 40 
can be significantly longer than 60 seconds. The scan- 
ner timing scheme is implemented to increase the inter- 
val between scans to a set maximum based on the his- 
tory of previous scans. The maximum is implemented 
as a failsafe device to prevent a complete shut down of 45 
the scanning procedure when there is no change in 
state. 

[0084] In case 3, if it can be detected that the laptop 
has moved, then the scanning engine 1000 performs a 
scan to check for available networks or access points 50 
as it is possible that the user can move out of range of 
the current network. Movement can be detected either 
in a location awareness module or through, in the case 
of an 802.11 NIC, analysis of 802.11 statistics, such as 
received signal strength, retransmission counts and 55 
frame error rates 

[0085] In accordance with an exemplary scanning 
scheme, the computing device also detects when there 



is another NIC providing network access (such as 
through an Ethernet cable). In this case, all scanning on 
the wireless NIC is wasted power and the NIC should 
be disabled. Even if the N IC remains enabled, it should 
not be requested to perform scanning. 
[0086] Furthermore, the scanning engine will detect 
when the NIC is actively sending traffic. This is an im- 
proper time to perform a scan and any scheduled scan 
should be delayed until traffic is sent. If the traffic is sent 
and the statistics are sufficiently good, a scanning peri- 
od is skipped. Finally, with regard to an exemplary scan- 
ning control scheme, the user might want to request a 
scan before the next scanning interval arrives. The NIC 
will perform this scan on demand and adjust the scan- 
ning history, period, timer, and frequency accordingly. 
[0087] It will be appreciated by those skilled in the art 
that a new and useful method and framework for facili- 
tating/performing automated configuration/selection of 
network access has been described herein. More par- 
ticularly, the rules-based network and interface selec- 
tion architecture described herein facilitates automated 
selection of a particular mode of network access based 
upon status information provided by a set of media spe- 
cific modules associated with multiple communication 
media. In view of the many possible computing environ- 
ments to which the principles of this invention may be 
applied and the flexibility of carrying out automated net- 
work access configuration, it should be recognized that 
the embodiment described herein is meant to be illus- 
trative and should not be taken as limiting the scope of 
invention. Those skilled in the art to which the present 
invention applies will appreciate that the illustrative em- 
bodiment can be modified in arrangement and detail 
without departing from the spirit of the invention. There- 
fore, the invention as described herein contemplates all 
such embodiments as may come within the scope of the 
following claims and equivalents thereof 



Claims 

1. A computing system supporting network selection 
based upon network information spanning multiple 
communication media, the system comprising: 

a rules data store for maintaining network se- 
lection criteria; 

a media specific module interface facilitating 
acquiring network interface information poten- 
tially spanning multiple communication media 
associated with a set of networks to which the 
computing system is capable of connecting via 
a set of network interfaces; and 
network selection logic for designating one of 
the set of networks by applying a network se- 
lection criterion from the rules data store to the 
accumulated network interface information po- 
tentially spanning multiple media. 
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2. The computing system of claim 1 wherein the media 
specific module interface and the network selection 
logic are associated with a rules engine having ac- 
cess to the rules data store. 

3. The computing system of claim 2 wherein the media 
specific module interface comprises a normaliza- 
tion module that receives requests from the rules 
engine directed to network interfaces. 

4. The computing system of claim 1 furthercomprising 
a set of media specific modules configured to ac- 
quire network interface information pertaining to 
network interfaces associated with particular media 
types. 

5. The computing system of claim 4 wherein the media 
specific modules acquire network interface informa- 
tion from media specific drivers associated with par- 
ticular network interfaces. 

6. The computing system of claim 1 wherein the mul- 
tiple communication media includes at least a wire- 
less wide area network media and a wireless local 
area network media. 

7. The computing system of claim 6 wherein the wire- 
less local area network media includes one or more 
of the 802.11 wireless protocols. 

8. The computing system of claim 1 wherein the net- 
work selection criterion specifies a preference order 
between at least two media based upon a network 
parameter associated with the media. 

9. The computing system of claim 1 wherein the net- 
work selection criterion specifies a preference order 
between at least two media based upon a network 
type associated with the media. 

10. The computing system of claim 1 wherein the net- 
work selection criterion specifies a preference order 
based upon a current location of the computing sys- 
tem. 

11. The computing system of claim 1 wherein the net- 
work selection criterion specifies a preference order 
between logical networks. 

12. The computing system of claim 1 wherein the net- 
work selection criterion specifies a preference order 
based upon a time parameter. 

13. The computing system of claim 1 wherein the net- 
work selection logic is incorporated into a state ma- 
chine that cyclically scans a set of network interfac- 
es for networks, applies the network selection crite- 
rion to a set of networks and interfaces to render a 



current network and interface selection, and issues 
configuration instructions in accordance with the 
current network and interface selection. 

5 14. The computing system of claim 1 further comprising 
a scanning engine associated with a network inter- 
face for controlling cyclical scanning based upon 
previous scan results maintained in a scanning his- 
tory. 

10 

15. A method for selecting a network and interface com- 
bination, to which a computing system will initiate a 
connection via the network interface, based upon 
network information spanning multiple communica- 

15 tion media, the method comprising: 

accessing a network selection criterion; 
accumulating network interface information po- 
tentially spanning multiple communication me- 
20 dia associated with a set of networks to which 

the computing system is capable of connecting 
via a set of network interfaces; and 
designating one of the set of networks and a 
network interface from the set of network inter- 
ns faces by applying a network selection criterion 
to the network interface information potentially 
spanning multiple media. 

16. The method of claim 15 wherein the network selec- 
30 tion criterion is accessed from a configurable rules 

data store. 

17. The method of claim 15 further comprising issuing 
network interface configuration instructions in ac- 

35 cordance with the designating step. 

18. The method of claim 15 wherein the accumulating 
step is facilitated by a normalization module inter- 
posed between a set of media specific modules as- 

40 sociated with potentially multiple distinct types of 
communication media drivers and a rules engine 
that performs the designating step. 

19. The method of claim 1 8 further comprising acquir- 
45 ing : by the media specific modules, network inter- 
face information from the communication media 
drivers associated with particular network interfac- 
es. 

50 20. The method of claim 1 5 wherein the multiple com- 
munication media includes at least a wireless wide 
area network media and a wireless local area net- 
work media. 

55 21 . The method of claim 1 5 wherein the network selec- 
tion criterion specifies a preference order between 
at least two media based upon a network parameter 
associated with the media. 
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22. The method of claim 1 5 wherein the network selec- 
tion criterion specifies a preference order between 
at least two media based upon a network type as- 
sociated with the media. 

23. The method of claim 1 5 wherein the network selec- 
tion criterion specifies a preference order based up- 
on a current location of the computing system. 

24. The method of claim 1 5 wherein the network selec- 
tion criterion specifies a preference order between 
logical networks. 

25. The method of claim 1 5 wherein the network selec- 
tion criterion specifies a preference order based up- 
on a time parameter. 

26. The method of claim 1 5 wherein the network selec- 
tion logic is incorporated into a state machine, and 
further comprising cyclically performing, under the 
control of the state machine: 

scanning a set of network interfaces for net- 
works; 

applying the network selection criterion to a set 
of networks and interfaces to render a current 
network and interface selection; and 
issuing configuration instructions in accord- 
ance with the current network and interface se- 
lection. 

27. The method of claim 1 5 further comprising initiating 
network scanning for a designated one or more of 
the set of network interfaces based at least in part 
upon a scanning algorithm and previous scan re- 
sults maintained in a scanning history. 

28. A computer-readable medium including computer- 
executable instructions for facilitating selecting a 
network and interface combination, to which a com- 
puting system will initiate a connection via the net- 
work interface, based upon network information 
spanning multiple communication media, the com- 
puter-executable instructions facilitating: 

accessing a network selection criterion; 
accumulating network interface information po- 
tentially spanning multiple communication me- 
dia associated with a set of networks to which 
the computing system is capable of connecting 
via a set of network interfaces; and 
designating one of the set of networks and a 
network interface from the set of network inter- 
faces by applying a network selection criterion 
to the network interface information potentially 
spanning multiple media. 

29. The computer-readable medium of claim 28 where- 



in the network selection criterion is accessed from 
a configurable rules data store. 

30. The computer-readable medium of claim 28 where- 
5 in the computer-executable instructions further fa- 
cilitate issuing network interface configuration in- 
structions in accordance with the designating step. 

31 . The computer-readable medium of claim 28 where- 
10 in the accumulating step is facilitated by a normali- 
zation module interposed between a set of media 
specific modules associated with potentially multi- 
ple distinct types of communication media drivers 
and a rules engine that performs the designating 

is step. 

32. The computer-readable medium of claim 31 further 
comprising computer-executable instructions for 
acquiring, by the media specific modules, network 

20 interface information from the communication me- 
dia drivers associated with particular network inter- 
faces. 

33. The computer-readable medium of claim 28 where- 
as in the multiple communication media includes at 

least a wireless wide area network media and a 
wireless local area network media. 

34. The computer-readable medium of claim 28 where- 
30 in the network selection criterion specifies a prefer- 
ence order between at least two media based upon 
a network parameter associated with the media. 

35. The computer-readable medium of claim 28 where- 
35 in the network selection criterion specifies a prefer- 
ence order between at least two media based upon 
a network type associated with the media. 

36. The computer-readable medium of claim 28 where- 
40 in the network selection criterion specifies a prefer- 
ence order based upon a current location of the 
computing system. 

37. The computer-readable medium of claim 28 where- 
45 in the network selection criterion specifies a prefer- 
ence order between logical networks. 

38. The computer-readable medium of claim 28 where- 
in the network selection criterion specifies a prefer- 

50 ence order based upon a time parameter. 

39. The computer-readable medium of claim 28 where- 
in the network selection logic is incorporated into a 
state machine, and further comprising computer- 

55 executable instructions for cyclically performing, 
under the control of the state machine: 

scanning a set of network interfaces for net- 
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works; 

applying the network selection criterion to a set 
of networks and interfaces to render a current 
network and interface selection; and 
issuing configuration instructions in accord- 
ance with the current network and interface se- 
lection. 

40. The computer-readable medium of claim 28 further 
comprising computer-executable instructions for in- 
itiating network scanning for a designated one or 
more of the set of network interfaces based at least 
in part upon a scanning algorithm and previous 
scan results maintained in a scanning history. 
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